The Software Communications Architecture (SCA) evolved out of efforts to provide for communications across global and local platforms and the inability of the present designs to integrate with rapid technological developments. The Department of Defense formed the Joint Tactical Radio System (JTRS) program in order to investigate a modular and scalable platform for simplifying applications engineering and exploiting technology improvements. The JTRS revealed that the optimal platform to satisfy the assessed needs was a software controlled and reprogrammable infrastructure, commonly called a software defined radio (SDR). A consortium of radio manufacturers joined forces to define a standard for software architecture, namely the SCA, to support the JTRS requirements. Subsequently, the SCA was contributed by the JTRS to the Object Management Group (OMG), which developed and approved an international modeling standard for SDR communications terminals called SWRadio.
In general, SDRs are used to describe radios that provide software control and reconfiguration of a variety of modulation techniques, wide-band or narrow-band operation, communications security functions (such as hopping), and waveform requirements of current and evolving standards over a broad frequency range. The frequency bands covered may still be constrained at the front-end, given a particular antenna system.
There are various types and implementations of SDR architectures, such as modal SDR and reconfigurable SDR, depending upon the application. There are practical considerations related to cost, size, power, and weight to contend with in addition to the performance characteristics desired. A basic block diagram of the SDR functional blocks is shown in FIG. 7. In general, there are four functional areas that need to be addressed by the SDR: front end processing 100, information security 160, information processing 170, and control 150.
Conventional front end processing 100 refers to input/output (I/O) interface (antenna 140), RF processing (RF section 110), RF/IF up/down conversions (IF section 120), and conversion between digital and analog signals (ADC/DAC 130). Modulation/demodulation processing is considered part of the front end processing. For received signals, the analog IF signal is converted to digital samples that are then digitally processed in the baseband section by the processing engine 170. The information processing engine 170 is used for decomposing or recovering information signals containing data, control, and timing. Information security 160 is employed for the purpose of providing user privacy, authentication, and information protection. Content processing and I/O functions map into path selection (including bridging, routing, and gateway), multiplexing, source coding, signaling protocol, and I/O functions. The extracted information signals are then delivered to the appropriate function via a control interface 150 connection.
The SDR architecture is designed to support functions connected through open interfaces, and procedures for adding software specific tasks to each of the functional areas. The software applications for the open architecture include multiple subsystems interconnected by open interfaces, wherein the subsystems are determined by implementation considerations. Each subsystem typically contains any required hardware, resident firmware, an operating system, and software modules that may be common to more than one application. Interfaces link the software application to specific modules within each subsystem. The application layer tends to be modular, flexible, and software specific, with a common software API layer.
The functional interface of the SDR architecture has interfaces that are implementation dependent with data and information traffic exchanged between the functional blocks along the interfaces. The interfaces can be described as information and control oriented with control over each of the functional blocks. The information transfer, control, and status data is between the various functional blocks including the antenna 140, RF section 110, IF section 120, processing engine 170, security section 160, and control interface 150. As an example, the frequency at which a wireless signal is generated is determined at the RF section 110 and can be changed to accommodate different operating environments, such as moving between geographic regions with different frequency assignments.
A basic RCA specification is set forth in SCA Specification 2.2, which establishes the architecture definition and rule sets governing SCA compliant hardware and software elements. This specification is herein incorporated in its entirety by reference, including the various additions and amendments to the SCA framework. One known SCA implementation imposes processing and memory requirements that violate or otherwise prohibit the form factor and power consumption constraints placed on lightweight radio cores. As a result, trying to implement the full SCA 2.2 framework requires an extraordinary amount of overhead to build a radio that would run a compliant waveform or application. The end result is a much higher cost for the radio system, larger form factor than desired, increased weight and greater power requirements. For many applications this does not satisfy the end-user requirements, whether military or commercial.
One approach taken to solve this overhead problem is to make the SCA implementation “lighter” by removing functionality. However none of the extensive list of processes and their functions can be eliminated and still maintain SCA 2.2 compliance. Another approach includes remotely launching the waveform/application. By this means, a remote process (referred to as a launcher) is created that runs on a system separate from the SCA core framework. It accepts a compiled application and executes it. The application utilizes the Object Request Broker (ORB) and other parts of the SCA processes it needs over a bus like an Ethernet network. This saves considerable memory and processor requirements in the remote radio core as the only processes running on the radio core is the launcher and the applications. However, this particular SCA lite approach has several disadvantages.
All SDR process communication is handled by an ORB or other such middleware enabling system. As explained in the white paper, “A Lightweight Software Communications Architecture (SCA) Launcher Implementation for Embedded Radio” (which is herein incorporated in its entirety by reference), the ORB is designated to run on the host system only, external to a remote radio core running its part of the radio processes. This means the remote core running the remote processes must stay connected to an external system. One of the greatest issues facing this implementation is data passing performance, since all inter processes and application communication utilizes an ORB as defined by the SCA 2.2. If two or more processes running on the remote core wish to communicate with each other, they must utilize the ORB that resides on the master system. This results in high traffic flow between the two systems and high delays in passing data between local processes. This was not a consideration in the white paper design and is a detriment in many real world SCA systems.
Secondly, conventional lightweight SCA concepts do not address the minimal parts of the SCA framework necessary to support running applications on a remote core. This results in a much larger footprint in terms of storage space.
Another issue with conventional lightweight SCA is that the application launcher is a slave to the host. In particular, it has no means of triggering/initiating a request for an application.
Another issue with conventional lightweight SCA is that it does not address any means that a remote core could start the last running application after a remote core boots up.
What is needed, therefore, is a software defined radio framework and processes that comply with the demands of commercial and military end-user requirements.